Prof 180x und mc68000-ECB

Der mc68000-ECB aus mc 1-3/87 ist ein Coprozessor-Board mit einem Motorola 68000 Prozessor auf einer Europakarte für den ECB-Bus. Diese Karte kann in jedem DMA-fähigen ECB-Bus-Computer eingesetzt werden, wobei dann abwechselnd oder auch gleichzeitig Z80- und 68000-Software gefahren werden kann. Im einfachsten Fall kann das 68000-Board aber auch nur dem Z80 eine bis 2MB große RAM-Floppy zur Verfügung stellen.

Wenn der Computer im 68000-Modus läuft, spielt der Z80 (oder im Prof 180x der HD64180) I/O-Knecht für den 68000. Der 68000 bedient sich des BIOS des CP/M 80. Der 8Bit-Prozessor wartet nur auf Aufgaben, die ihm der 68000 stellt.

Die Kommunikation zwischen den beiden CPUs ist für beide unterschiedlich zu handhaben. Der 8Bit-Prozessor kann dem 68000 einen 1Byte-Befehl in ein Latch schreiben, während der 68000 per DMA in den Speicher des Wirts-Computers schreiben und auch daraus lesen kann. In den 16MB-Adreßraum des 68000 ist ein Fenster von 2MB Größe gelegt, in dem die vermeintlichen 64KByte des Z80-Systems erreichbar sind. Zur Adressierung im Z80-System werden dann die Adressen A1-A16 des 68000 auf A0-A15 des ECB-Bus geschaltet und BUSAK* low gezogen. Außerdem werden auch die Z80-kompatiblen Signale MERQ* IORQ*, RD* und WR* erzeugt und der Datentreiber des 68000-Boards zum ECB-Bus wird freigegeben (für D8-D15 des 68000).

Der Prof 180x hat aber nicht nur 64KBte RAM; zur Adressierung innerhalb der 512K des Prof 180x müssen noch die Adressen A16-A18 mit festen Pegeln für den Bereich 40000H-4FFFFH erzeugt werden. In diesem physikalischen Adreßbereich liegt im Prof die TPA, in der ein Kommunikationsprogramm den Datenaustausch mit dem 68000 erledigt und von wo der 68000 sich Daten abholt und wohin er seine Daten an das 8Bit-System überträgt. Das läßt sich noch recht einfach mit einem 74LS367 Tri- state-Treiber, der A16-A18 des ECB-Bus bedient, auf dem 68000-Board erledigen. Dieser Treiber wird mit den Pins 1, 8 und 16 auf IC33, 74LS367 aufgelötet. Die Pins 3, 5 und 7 werden mit A18, A17 und A16 des ECB-Bus verbunden und an Pin 2 wird ein Widerstand von 4K7 gegen +5V angeschlossen. Die Pins 4 und 6 werden an GND gelegt.

Das eigentliche Problem war weder vorher abzusehen noch durch einen einfachen Patch zu beheben - so schien es zumindest im ersten Augenblick. Die DMA-Fähigkeit des Prof 180x brücksichtigt zunächst die Steuerung der Treiber zum ECB-Bus. Durch ein PAL 14L8 ist die Bussteuerung ohne den sonst für die Berücksichtigung der DMA-Fähigkeit nötigen TTL-Aufwand mit folgender PAL-Gleichung für das Steuersig- nal des Datentreibers gelöst:

/DIR = /IOE * /RD * /ADR * A7 * /A5	;Treiberrichtung bei Lesen interner
					;Ports immer zum BUS hin
     + /ME * /RD * A19                  ;zum Bus bei Lesen der internen 512K
					;A19 ist ein im gleichen Pal erzeugtes 
					;Signal zur Unterscheidung von internem
					;und externem RAM
     + RD * LIR * BUSAK			;zum Bus auch, wenn weder ein Interrupt-
					;Achnowledge noch DMA-Zugriff noch eine
					;Schreiboperation erfolgt

Die Treiber für den Adreßbus und Steuerbus werden einfach durch den Pegel von BUSAK* gesteuert, Wenn BUSAK* low aktiv ist, treiben diese die entsprechenden Signale vom Bus zur CPU-Karte.

Damit kann ein externer DMA-Controller zwar auf das CPU-Board zugreifen aber noch nicht den Speicher lesen und schreiben, denn das flexibel bei jeder CPU-Taktrate funktionierende Timing der RAM-Steuersignale RAS*, MUX und MUX* und CAS*, das aus HDD4180-spezifischen Signalen abgeleitet wird, kann von einem DMAC nicht unterstützt werden. Die im Prof 180X verwendete Schaltung (Abb.2) zeigt, daß aus dem MERQ* mit der nächsten steigenden Flanke des Systemtaktes die Signale MUX und MUX* erzeugt werden und daß ein vom Systemtakt abhängiges HD64180-speifisches Signal E für das Timing des CAS*-Signals herangezogen wird. Ein asnchron arbeitender DMAC kann diese Signale garnicht bedienen, E ist ein ECB-Bus-Signal und der CPU-Takt ist kein Tristate-Signal, das beim DMA-Zugriff vom DMAC bedient werden kann.

Es galt nun, möglichst unter Beibehaltung des eleganten und flexiblen Timings der RAM-Steuerung durch den HD64180, einem externen DMAC eine weitere Möglichkeit zu schaffen, ausschließlich mit MERQ* (=ME* beim HD64180) und Verzögerungsgliedern die getimeten RAM-Signale zu erzeugen. Wenn dies z.B. mit Gatterlaufzeiten gemacht wird, sind dann allerdings der Bandbreite möglicher Tatraten des DMAC engere Grenzen gesetzt. Die in Abb.3 dargestellte Schaltung erlaubt das durch BUSAK* gesteuerte Umschalten zwischen ursprünglichem Timing des Prof 180x und über Gatterlaufzeiten geregeltes Timing bei Kontrolle durch den externen DMA- Controller. Die Anzahl Gatter für die Verzögerung gilt für einen mit 8MHz getate- ten 68000. Bei Verwendung entsprechend schneller RAMs und EPROMs auf dem 68000- Board macht diese Schaltung aber auch bei einem mit 16MH getakteten 68000 mit.

Es sei noch erwähnt daß im DMA-Betrieb MUX und CAS* nicht gleichzeitig kommen, wie die Schaltung beim ersten Hinsehen erwarten läßt. Das im PAL aus E erzeugte CAS* ist gegenüber E nochmals um die Gatterlaufzeit des PALs verzögert.

Die Schaltung sieht auf den ersten Blick nach sehr viel Flick- und Sägearbeit am CPU-Board aus. Das ist aber durch Verwenden eines kleinen Adapterplatinchens, das in den Sockel von Z9, 74S74 gesteckt wird und Z9 selbst mit aufnimmt, nicht der Fall. Außer dem 74S74 bringt das Platinchen noch ein 74LS367 (Tristate-Treiber) und ein 74LS368 (invertierender Tristate-Treiber) unter, über den Sockel von Z9 werden fast alle benötigten Signale (MERQ*, CLK, RFS*) dem Platinchen zugeführt und auch die jeweils erzeugten Signale MUX und MUX* abgeleitet. BUSAK* muß durch freie Verdrahtung von J9 und E von Pin60 des HD64180 bezogen werden. Das Ausgangssignal E wird an Pin7 des PALs gelegt. Damit die bisherige Verbindung zwischen Pin60 des HD64180 und Pin7 des PALs unterbrochen wird, muß Pin7 des PALs aus der Fassung gebogen werden.

Eine ähnliche Herleitung von MUX und/oder MUX* weisen einige moderne TRS80- kompatible Computer auf, bei denen eine Taktumschaltung zwischen 1,77MHz und einer anderen, deutlich höheren Geschwindigeit möglich ist: Leider ist in all diesen Geräten ein nicht DMA-fähiger Bus konstruiert worden. Ein externer DMAC kann hier nur direkt mit den entsprechenden Signalen der CPU verbunden werden, Unverständlicheiweise werden dann aber die Treiber für Adreß- und Steuerbus doch durch ein invertiertes BUSAK* oder BUSRQ* freigegeben. Offensichtlich haben ganze Generationen von Konstruteuren von einem Urtrottel abgeguckt. Deshalb muß man dann zusätzlich noch die Freigabe dieser Treiber mit GND anstelle mit BUSAK bzw. BUSRQ einrichten.